REMARKS 



Claims 55 - 85 are currently pending in this response. Claims 55 - 85 are 
rejected. Claims 55, 80 and 81 are amended in this response. 



Claim Rejections - 35 USC 103 

The Examiner rejected claims 55 - 85 under 35 USC 102(e), as being 
obvious over Helgeson et al. US Patent No. 6643652, and associated application No 
2002/0073236, in view of Brown, US Patent Application No. 2003/0061317 and 
further in view of Arunachalam US Patent Publication No. 2003/0069922 A 1 

Applicant has specifically limited claims 55, 80 and 81 to positively recite 
that the first and second identity arrangements are 1) within the software objects and 
2) contain identities. 

Examiner rejects claim 55 inter alia on the ground that the software first 
and second identity arrangements contained within software objects are to be found in 
Arunachalam Fig. 6 items 630 and 640. 

However Arunachalam item 630 is a hub. A hub is not a software object, 
nor is it contained in a software object. In this case, the term "hub" refers to a web 
server, or similar device, as described in paragraph 56. As part of a hub-and-spoke 
(we note that Arunachalam uses the term "node" instead of "spoke") architecture any 
identifier of a hub cannot be parallel to an identifier in the present invention, because 
the relationship of a hub to its spokes requires that the spokes are dependent on the 
hub, and thus the relationship is essentially different from the relationship of a user 
and a provider. In the latter case the user and provider are independent of each other. 

Thus Arunachalam does not teach a first identity arrangement since item 
630 is not an identity arrangement but a hub. 

Arunachalam item 640 is a series of nodes. The nodes 640 are web servers 
connected to hubs in a hub-and-spoke configuration. 

In fact item 640 comprises several nodes, so it is not even conceivable that 
there is a unique identity for the group of nodes. If what the Examiner is assuming is 
that each node has an identity, this is still not comparable to identities of the present 
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embodiments, because nodes have a dependent relationship with respect to hubs, as 
mentioned above. 

Since Arunachalam does not have software identity arrangements that are 
parts of software objects, these identity arrangements cannot manage distributed 
service and software objects or components. While it is agreed that Arunachalam 
does have distributed software objects, any identification of hubs and nodes in 
Arunachalam plays a role essentially different from the first and second identity 
arrangements of the present embodiments. (It is also noted that hubs and nodes 
represent two different kinds of entities, while claim 55 of the present invention refers 
to only one kind of software object.) 

No such feature of preservation of a first and second identity arrangement 
stored with a first software object to allow independent manipulation thereof is taught 
in either Helgeson or Brown. Arunachalan item 630 is not an identity arrangement 
contained within a software object and which contains an identity. 

Column 5 paragraph 68 of Arunachalam discusses hub 630. It is described 
as a "service network control center or network operator". This is a far cry from an 
identity arrangement on a software object as claimed. 

Arunachalam item 640 is a series of nodes. These again are computers on a 
network, each connected to a hub. Item 640 is not an identity arrangement within a 
software object, each containing an identity. Neither, for that matter are the individual 
nodes. As noted in Arunachalam paragraph 71, the nodes may serve as "a gateway, 
portal or entry point into a private or enterprise network of the service provider". This 
is a far cry from an identity arrangement on a software object as claimed. It certainly 
would not include an identity of a remote object. 

Although these nodes and hub do interact, there is no teaching in the 
reference of manipulation of remote objects independently through these identity 
arrangements since Arunachalam does not have identity arrangements within software 
objects. 

Paragraph 133 of Arunachalam does indeed teach allowing a remote object 
to be called the same thing as a local object. Our understanding of Arunachalam is 
that a remote object can be called in the same way as a local object, however, not that 
a remote object can be substituted for a local object. 
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Irrespective of this understanding, Arunachalam's teaching is the exact 
opposite of what is claimed, where each object has a unique identity, and is therefore 
not interchangeable with another object. 

Thus, precisely Arunchalam paragraph 133 would lead the skilled person 
reading Hegelson and Brown to abandon unique identities. 

The skilled person would naturally read the paragraph pointed to by the 
Examiner, but would in fact be misled by the teaching there and would not provide 
unique identities to his objects. 

As a result, independent data manipulation as claimed cannot be 
guaranteed. 

As the Examiner accepts (page 4 last paragraph) that Hegelson and Brown 
fail to teach 

wherein said first and said second identity arrangements, being 
contained within said hosted software objects and comprising said 
respective unique identities, enable a plurality of remote entities to 
access said enablement data of a first of said hosted software objects 
simultaneously, said respective host and second identity arrangements 
being preserved with said access such that manipulations of said 
software object by any one of said remote entities is independent of 
manipulation of said remote object by any other remote entities, and 
wherein each respective second, relationship, identity is transferrable 
with correspondingly independently manipulated data to another one of 
said hosting servers for a second manipulation with a further software 
object at said another hosting server, said second manipulation 
preserving said second, relationship, identity, thereby allowing said 
respective remote entity to retain a relationship with said further 
software object after manipulation thereof through said first software 
object, 

and that the items pointed to an Arunachalam are in fact a hub and spokes in 
dependent relation, and not identity arrangements stored in software objects and 
containing software, it is believed that the rejections are overcome. 

Furthermore, as stated, paragraph 133 of Arunachalam teaches away from 
providing unique identities to objects, contrary to what is claimed, so that when 
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Arunachalam is combined with Hegelson and Brown, the skilled person is prevented 
from arriving at the present invention. 

As a side issue, Applicant still cannot accept the logic of the Examiner in 
claiming that the hosting servers holding a first identity is found in the XML protocol 
of Hegelson. While it is true that XML protocol could be used for many purposes, the 
reference does not teach an identity arrangement holding an identity of a hosting 
server. Examiner is required to find the actual feature claimed, not something that the 
reference could have done but did not. 

Equivalent amendments have been made to independent claims 80 and 81, 
which are believed to be inventive for the same reasons. 

The inventor adds the following notes on Arunachalam: 

Arunachalam does, indeed, like the present invention, address the problem of 
involving multiple, remote, entities in a single transaction, however it addresses a 
much lower-level set of problems, now usually addressed by Web Services. This 
paragraph best expresses Arunachalam's goals: 

[0012] As the Web expands and electronic commerce becomes more 
desirable, the need increases for robust, real-time, bi-directional transactional 
capabilities on the Web. A true real-time, bi-directional transaction would 
allow a user to connect to a variety of services on the web, and perform real- 
time transactions on those services. 
This need, in fact, was subsequently met by what are now called "Web Services". 
Web Services comprise part of the background of the present invention. 

The present invention addresses the higher-level problem of how to integrate multiple, 
remote, entities in a single transaction ad-hoc. The obvious solution for integrating 
multiple, remote, entities in a single transaction is the one that Arunachalam does, in 
fact, give as the embodiment of its invention: a hub-and-spoke architecture 
(Arunachalam uses the term "node" instead of "spoke"): 

[0048] ... Advantageously, this may allow sophisticated, real-time, multi- 
service provider transactions to be performed while allowing one entity (e.g. a 
context owner) to control the transaction. 
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The problem, for the purpose of the present invention, is that integration using a hub- 
and-spoke architecture cannot be ad-hoc. The hub must be integrated with its spokes 
before the spokes can interact, since it is the hub that controls the transaction: 

[0056] ... The term "hub" will broadly be used to refer to one or more 
functionally coupled computer systems (e.g. a web server server) that provide 
software and methods to control a transaction or service involving multiple 
service providers. 

One of the central features of the present invention is that it eliminates this need by 
eliminating the hub. 

To use Arunachalam's example to illustrate the present invention: A customer wants 
to buy a car, and pay for it from his bank account. Using Arunachalam's solution, the 
customer would purchase the car from the car dealer, then the car dealer would 
connect to the bank using the Arunachalam invention (or, more realistically, Web 
Services), and get the money. In this case the car dealer is the "hub" and the bank is 
the "spoke". This solution would require previous integration of the car dealer with 
the bank, otherwise the car dealer wouldn't even know of the existence of the bank's 
interface, let alone how to use it. On the other hand, using the present invention, no 
prior integration is necessary. Why? Because the customer "owns" an object in the 
bank's web site, called his "bank account object," as indicated by the object's second 
identity arrangement (the object's first identity arrangement identifies the bank, its 
third identity arrangement identifies the specific account object, since the same 
customer is likely to "own" many "bank objects" of different kinds). That object 
"belongs" to the customer to do what he wants with it. Similarly, the customer "owns" 
a "car object" in the car dealer's web site, which also "belongs to him". The present 
invention provides a way for objects to describe themselves (claims 59 and 60), 
enabling the customer to simply drag-and-drop the "account object" on the "car" 
object to pay for it. The objects will know what to do because they are both self- 
described. There are no identity arrangements in Arunachalam similar to the first and 
second identity arrangements that enable a user to "own" objects which are supplied 
by service provider's web sites. 
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Conclusion 

All the matters raised by the Examiner are believed to have been dealt with. 

Claims 55, 80 and 81 are believed to be inventive over the combination of 
Hegelson and Brown. 

All the dependent claims are believed to be allowable as being dependent on 
allowable main claims. 

All the matters raised by the Examiner have been dealt with and allowance of 
the application is respectfully awaited. 



Respectfully submitted, 

/Jason H. Rosenblum/ 

Jason H. Rosenblum 
Registration No. 56,437 
Telephone: 718.246.8482 



Date: November 12, 2009 
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